A universal mobile telecommunications system (UMTS) is a third-generation mobile communications system evolving from a global system for mobile communications system (GSM), which is the European standard. The UMTS is aimed at providing enhanced mobile communications services based on the GSM core network and wideband code-division multiple-access (W-CDMA) technologies.
In December 1998, ETSI of Europe, ARIB/TTC of Japan, T1 of the United States, and TTA of Korea formed a Third Generation Partnership Project (3GPP) for creating detailed specifications of the UMTS technology. Within the 3GPP, in order to achieve rapid and efficient technical development of the UMTS, five technical specification groups (TSG) have been created for determining the specification of the UMTS by considering the independent nature of the network elements and their operations.
Each TSG develops, approves, and manages the specification within a related region. Among these groups, the radio access network (RAN) group (TSG-RAN) develops the specifications for the functions, requirements, and interface of the UMTS terrestrial radio access network (UTRAN), which is a new radio access network for supporting W-CDMA access technology in the UMTS.
A related art UMTS network structure 1 is illustrated in FIG. 1. As shown, a mobile terminal, or user equipment (UE) 2 is connected to a core network (CN) 4 through a UMTS terrestrial radio access network (UTRAN) 6. The UTRAN 6 configures, maintains and manages a radio access bearer for communications between the UE 2 and the core network 4 to meet end-to-end quality of service requirements.
The UTRAN 6 includes a plurality of radio network subsystems (RNS) 8, each of which comprises one radio network controller (RNC) 10 for a plurality base stations, or Node Bs 12. The RNC 10 connected to a given base station 12 is the controlling RNC for allocating and managing the common resources provided for any number of UEs 2 operating in one cell. One or more cells exist in one Node B. The controlling RNC 10 controls traffic load, cell congestion, and the acceptance of new radio links. Each Node B 12 may receive an uplink signal from a UE 2 and may transmit a downlink signals to the UE 2. Each Node B 12 serves as an access point enabling a UE 2 to connect to the UTRAN 6, while an RNC 10 serves as an access point for connecting the corresponding Node Bs to the core network 4.
Among the radio network subsystems 8 of the UTRAN 6, the serving RNC 10 is the RNC managing dedicated radio resources for the provision of services to a specific UE 2 and is the access point to the core network 4 for data transfer to the specific UE. All other RNCs 10 connected to the UE 2 are drift RNCs, such that there is only one serving RNC connecting the UE to the core network 4 via the UTRAN 6. The drift RNCs 10 facilitate the routing of user data and allocate codes as common resources.
The interface between the UE 2 and the UTRAN 6 is realized through a radio interface protocol established in accordance with radio access network specifications describing a physical layer (L1), a data link layer (L2) and a network layer (L3) described in, for example, 3GPP specifications. These layers are based on the lower three layers of an open system interconnection (OSI) model that is well known in communications systems.
A related art architecture of the radio interface protocol is illustrated in FIG. 2. As shown, the radio interface protocol is divided horizontally into a physical layer, a data link layer, and a network layer, and is divided vertically into a user plane for carrying data traffic such as voice signals and Internet protocol packet transmissions and a control plane for carrying control information for the maintenance and management of the interface.
The physical layer (PHY) provides information transfer service to a higher layer and is linked via transport channels to a medium access control (MAC) layer. Data travels between the MAC layer and the physical layer via a transport channel. The transport channel is divided into a dedicated transport channel and a common transport channel depending on whether a channel is shared. Also, data transmission is performed through a physical channel between different physical layers, namely, between physical layers of a sending side (transmitter) and a receiving side (receiver).
The second layer includes a MAC layer, a radio link control (RLC) layer, a broadcast/multicast control (BMC) layer and a packet data convergence protocol (PDCP) layer. The MAC layer maps various logical channels to various transport channels. The MAC layer also multiplexes logical channels by mapping several logical channels to one transport channel. The MAC layer is connected to an upper RLC layer via the logical channel. The logical channel can be divided into a control channel for transmitting control plane information a traffic channel for transmitting user plane information according to the type of information transmitted.
The MAC layer is divided into a MAC-b sublayer, a MAC-d sublayer, a MAC-c/sh sublayer, a MAC-hs sublayer and a MAC-e sublayer according to the type of transport channel being managed. The MAC-b sublayer manages a broadcast channel (BCH), which is a transport channel handling the broadcast of system information. The MAC-c/sh sublayer manages common transport channels such as an FACH (Forward Access Channel) or a DSCH (Downlink Shared Channel) that is shared by other terminals. The MAC-d sublayer handles the managing of a DCH (Dedicated Channel), namely, a dedicated transport channel for a specific terminal. In order to support uplink and downlink high speed data transmissions, the MAC-hs sublayer manages an HS-DSCH (High Speed Downlink Shared Channel), namely, a transport channel for high speed downlink data transmission, and the MAC-e sublayer manages an E-DCH (Enhanced Dedicated Channel), namely, a transport channel for high speed uplink data transmissions.
The RLC layer guarantees a quality of service (QoS) of each radio bearer (RB) and handles the transmission of corresponding data. The RLC layer includes one or two independent RLC entities for each RB in order to guarantee a particular QoS of each RB. The RLC layer also provides three RLC modes, namely, a Transparent Mode (TM, an Unacknowledged Mode (UM) and an Acknowledged Mode (AM), to support various types of QoS. Also, the RLC controls the size of data to be suitable for a lower layer in transmitting over a radio interface. For this purpose, the RLC segments and concatenates the data received from the upper layer.
A PDCP (Packet Data Convergence Protocol) layer is a higher layer of the RLC layer and allows the data transmitted through a network protocol (such as an IPv4 or IPv6) to be effectively transmitted over a radio interface with a relatively small bandwidth. To achieve this, the PDCP layer performs a header compression function wherein only necessary information is transmitted in a header part of the data to thereby increase transmission efficiency over the radio interface. Because the PDCP layer performs the header compression as a basic function, it exists only at a packet switched (PS) domain. One PDCP entity is provided per RB to provide an effective header compression function with respect to each PS service.
A BMC (Broadcast/Multicast Control) layer, located at an upper portion of the RLC layer in the second layer (L2), schedules a cell broadcast message and broadcasts the message to terminals located in a specific cell.
A radio resource control (RRC) layer located at the lowest portion of the third layer (L3) is defined in the control plane and controls the parameters of the first and second layers with respect to the establishment, reconfiguration and release of RBs. The RRC layer also controls logical channels, transport channels and physical channels. Here, the RB refers to a logical path provided by the first and second layers of the radio protocol for data transmission between the terminal and the UTRAN. In general, the establishment of the RB refers to stipulating the characteristics of a protocol layer and a channel required for providing a specific data service, and setting their respective detailed parameters and operation methods.
The details of the RLC layer will be now be explained. The RLC layer guarantees a QoS of each RB and transmits data according to the QoS. Because the second layer of the radio protocol provides the RB service to an upper layer, the entire second layer influences the QoS; particularly, the RLC influences the QoS. The RLC establishes an independent RLC entity for every RB in order to assure an intrinsic (unique) QoS of the RB. Various types of QoS are supported by using the TM, the UM and the AM modes. The three RLC modes support different QoS from one another, and different operation methods are used for each mode. The detailed functions thereof are also different.
Each RLC operation mode (TM, UM and AM) will be now explained. First, the TM RLC is a mode in which an RLC SDU transferred from an upper layer does not have any overhead for constructing an RLC PDU. That is, the RLC passes the SDU transparently and hence is named “transparent” mode RLC. The TM RLC with this characteristic performs the following functions in the user plane and the control plane.
In the user plane, because of a short data handling time in the RLC, the TM RLC manages a transmission of real-time circuit data such as voice or streaming data of a circuit service domain (CS domain). While in the control plane, there is no overhead in the RLC such that the TM RLC manages a transmission of an RRC message from a non-specific UE on the uplink and a transmission of an RRC message broadcast to all UEs within a cell on the downlink.
Unlike the TM mode, a mode in which an overhead is added at the RLC is referred to as a non-transparent mode. The non-transparent mode includes an unacknowledged mode (UM), which does not receive an acknowledged response for transmitted data, and an acknowledged mode (AM), which does receive an acknowledged response. The UM RLC sends PDUs, each of which having a PDU header containing a sequence number (SN) added thereto, so as to allow a receiver to know which PDU has been lost during data transmission. By this function, the UM RLC manages in the user plane, a transmission of broadcast/multicast data or real-time packet data such as voice (e.g., VoIP) or streaming data of a PS domain. Simultaneously, the UM RLC manages in the control plane, a transmission of an RRC message, which does not require a reception acknowledged response, among RRC messages transmitted to a specific UE or a specific UE group within a cell.
The AM RLC, similar to the UM RLC, constructs a PDU by adding a PDU header containing the SN and sends the PDU to a receiver. However, unlike the UM RLC, the receiver sends an acknowledgment for the PDU transmitted from a transmitter in the AM RLC. By sending the acknowledgment, the receiver can request the transmitter to retransmit a PDU that was unsuccessfully received. This is the most essential characteristic of the AM RLC.
As a result, the AM RLC aims to guarantee an error-free data transmission by performing retransmissions. Accordingly, the AM RLC manages the transmission of non-real time packet data such as a TCP/IP (Transmission Control Protocol/Internet Protocol) of the PS domain in the user plane. In the control plane, the AM RLC manages a transmission of an RRC message requiring a reception acknowledged response among the RRC messages transmitted to a specific UE within a cell.
Furthermore, regarding the directional properties, the TM RLC and the UM RLC are used for uni-directional communication, while the AM RLC is used for bi-directional communication because of the feedback from the receiver. Bi-directional communication is usually used in a point-to-point communication scheme. Thus, the AM RLC uses only a dedicated logical channel. In addition, in the schematic aspect of the three operational modes, transmission or reception is achieved by one RLC entity in the TM RLC and the UM RLC. However, in the AM RLC, both the transmitter and the receiver each have one RLC entity.
The AM RLC has a complicated scheme because of its retransmission function. The AM RLC includes a retransmission buffer in addition to a transmission/reception buffer for managing retransmissions. In particular, the AM RLC performs various functions such as using a transmitter/receiver window for flow control, using a polling procedure by which a transmitter requests status information from a receiver of a peer RLC entity, reporting status information by which the receiver reports its own buffer state to the transmitter of the peer RLC entity, using a status PDU carrying the status information, using a piggyback procedure to insert the status PDU into a data PDU for increasing the efficiency of data transmissions, as well as other functions.
In the AM RLC, when a serious error is found during an operation of the AM RLC entity, a reset PDU for requesting the AM RLC entity of a counterpart to reset some or all operations and parameters, a reset ACK PDU for providing a response with respect to the reset PDU, or the like, are used. For supporting these functions, the AM RLC must have various protocol parameters, status variables and a timer.
A PDU used for controlling a data transmission in the AM RLC, such as the status information report or the status PDU and the reset PDU, is referred to as a control PDU. A PDU used for transferring user data is referred to as a data PDU. Hence, the PDUs used in the AM RLC are generally divided into data PDUs and control PDUs. The control PDUs are further classified into four different PDUs, namely, a status PDU, a piggybacked status PDU, a reset PDU and a reset ACK PDU.
In general, a reset procedure corresponds to a situation requiring the use of the control PDU. The reset procedure is used for solving erroneous situations at an operation of the AM RLC, such as situations where different sequence numbers are used, or where a PDU (or SDU) has been unsuccessfully transmitted more than a certain number of times. When using the reset procedure, the AM RLCs of the receiver and the transmitter initialize their environment variables to enter into a state that again allows communication.
First, a party that decides to initiate the reset procedure, namely, the AM RLC of the transmitter, transmits to the receiver a reset PDU containing an HFN (Hyper Frame Number) value of its transmitting direction that is currently being used. When the reset PDU is delivered, the AM RLC of the receiver resets the HFN value of its receiving direction and initializes the environment variables such as a sequence number. Also, the AM RLC of the receiver transmits a reset ACK PDU containing the HFN of its transmitting direction to the AM RLC of the transmitter. When the reset ACK PDU is received, the AM RLC of the transmitter resets the HFN value of its receiving direction and then initializes the environment variables.
Hereinafter, the format of an RLC PDU used in an AM RLC entity will be described. FIG. 3 illustrates a format of an AM RLC PDU, a data PDU used when transmitting data. Referring to FIG. 3, the AM RLC PDU is used when the AM RLC entity desires to transmit user data or piggybacked status information and a polling bit. A portion of the user data comprises 8 bits or integer multiples thereof. A header of the AM RLC PDU comprises a sequence number having a size of two octets. Also, a portion of the header of the AM RLC PDU includes a length indicator.
FIG. 4 illustrates a format of a status PDU (STATUS PDU). The status PDU comprises plurality of SUFIs (Super Fields), each of which can be different from one another. A size of the status PDU is variable or restricted to be the same size as the size of the greatest RLC PDU of a logical channel by which the status PDU is transmitted. Here, the SUFIs perform the function of reporting information about which AM RLC PDU has been successfully or unsuccessfully received at the receiving end, or may contain indications necessary for varying a size or a position of a receiver window. Each SUFI is formed of three parts of parameters including a type, a length and a value.
FIG. 5 illustrates a format of a piggybacked status PDU. The piggybacked status PDU has a similar format to that of the status PDU, but it is different therefrom in that a D/C field is substituted for a reserved bit (R2). This piggybacked status PDU is inserted into the AM RLC PDU when the AM RLC PDU has sufficient space remaining therein. Here, the PDU type value is always defined as 000.
FIG. 6 illustrates a format of a reset PDU/reset ACK PDU. The reset PDU contains a sequence number called an “RSN” having a size of one bit. The reset ACK PDU is transmitted as a response for a received reset PDU, whereby the reset ACK PDU is transmitted together with the RSN that is contained in the received reset PDU.
In this case, the parameters used in the PDU format may be indicated as follows.
D/C field: This value informs whether a corresponding PDU is a control PDU or a data PDU.
PDU type: This value informs of a type of the control PDU. Specifically, this value informs whether the corresponding PDU is a reset PDU or a status PDU.
Sequence number: This value refers to sequence number information of the AM RLC PDU.
Polling bit: This value is set when requesting a status report to a receiver.
Extension bit (E): This value refers to whether or not the following octet is a length indicator.
Reserved bit (R1): This value is used for a reset PDU or a reset ACK PDU and coded as 000.
Header extension bit (HE): This value refers to whether the following octet is a length indicator or data.
Length indicator: This value informs of a position of a boundary between different SDUs, if such exists within a data portion of a PDU.
PAD: This portion refers to a padding region that is not used in the AM RLC PDU.
Hereafter, HSDPA (High Speed Downlink Packet Access) technology will be explained. As wireless Internet access technology becomes more popular and subscribers therefore continue to increase, various services related thereto are being provided. Thus, techniques and systems allowing higher transmission rates are needed for supporting these services. In 3GPP, research for enhancing UMTS network technologies and providing higher transmission rates are being conducted. Particularly, the HSDPA (High Speed Downlink Packet Access) system is getting much attention.
Various new techniques have been introduced for supporting the HSDPA. One of these techniques is the HARQ (Hybrid Automatic Repeat Request) technique. The HARQ technique is a retransmission method, which is different from the retransmission method for packets performed by the RLC layer. The HARQ method is used in connection with a physical layer and combines retransmitted data with a previously received data so as to guarantee a higher restoring (decoding) ratio. Specifically, in the HARQ technique, an unsuccessfully transmitted packet is not discarded but stored, and then combined with a retransmitted packet prior to a coding step so as to restore (decode) that packet.
In order to support the HARQ function more effectively, a HARQ block exists in the MAC-hs sublayer of a Node B. The HARQ block includes HARQ entities for managing the HARQ operation of a UE to be supported. Also, one HARQ entity exists with respect to each UE. Furthermore, each HARQ entity has various HARQ processes therein, each process being used for handling the control of the HARQ operations and used for transmitting specific data. Each HARQ process may share and use a plurality of data units, but only one is processed for one TTI (Transmission Time Interval). Therefore, when data transmission is successful, the HARQ process becomes empty and thus may be used for transmitting other data. However, when data transmission is unsuccessful, the HARQ process continues to store the corresponding data until it is successfully transmitted or discarded.
Considering the data transmission in the MAC-hs of the Node B in more detail, the Node B reconstructs (decodes) data units received from the RNC to generate MAC-hs PDUs. The corresponding PDUs are then allocated to each HARQ process. In this case, the MAC-hs PDUs transmitted from each HARQ process may be successfully sent to a UE all at once; however, this may not always be the case.
For instance, assume that a previously generated MAC-hs PDU#1 is allocated to a HARQ process A and a subsequently generated MAC-hs PDU#2 is allocated to a HARQ process B. In general, each HARQ process does not perform transmission simultaneously, but respectively operates independently. Therefore, when the HARQ process A is continuously unsuccessful in transmitting the MAC-hs PDU#1 and the HARQ process B successfully transmits the MAC-hs PDU#2 earlier than the HARQ process A, it may occur that the MAC-hs PDU#2 containing the subsequently generated data (namely, the data that arrives at the Node B later) may be received and processed by the UE earlier than the previously generated MAC-hs PDU#1 and then processed. That is, according to the HARQ process, the MAC-hs PDUs may not always be delivered to the UE in the order in which they were generated at the Node B. As a result, the RLC PDUs contained in the MAC-hs PDU may also not necessarily be delivered to the RLC in sequential order.
The related art has been designed to allow PDUs to arrive at the AM RLC of a receiver in the order that they were transmitted by the AM RLC of a transmitter. That is, in the related art, when the AM RLC of the receiver received a control PDU, that received control PDU was determined to have been transmitted subsequent to a last received RLC PDU, and the received control PDU was immediately processed.
However, as aforementioned, a technique such as HSDPA transmits PDUs by using various HARQ processes at once, such that the PDUs are not delivered to the AM RLC of the receiver in the order that they were transmitted from the AM RLC of the transmitter. This situation is referred to as an ‘out of sequence delivery’. In other words, PDUs which should be delivered later may arrive at the receiver earlier than the former generated PDUs. In spite of this, if the AM RLC of the receiver immediately processes a corresponding control PDU as soon as it is delivered, like in the related art, proper communication may not continue, thus leading to serious problems.
For instance, assume that an AM RLC performs a reset procedure. In the reset procedure, the AM RLC of the transmitter first transmits to the receiver a reset PDU, which is a type of control PDU containing the HFN value currently being used for its transmitting direction. Then, upon receiving delivery of the reset PDU, the AM RLC of the receiver resets the HFN value of its receiving direction and also initializes a sequence number thereof.
However, for the AM RLC PDUs transmitted prior to the reset PDU, the HFN values before performing a reset procedure are used. Moreover, the sequence numbers before initialization are used. If the AM RLC PDUs, which have been generated and transmitted prior to the reset PDUs, arrive at the receiver subsequent to the reset PDUs, then the subsequent-arriving AM RLC PDUs would be interpreted to have arrived after the environment variables of the receiver had already been upgraded to new values by the reset PDU. Therefore, the AM RLC of the receiver can not properly restore (decode) the AM RLC PDUs that used previous environment variables before any updating. Furthermore, the AM RLC of the receiver undesirably continues to update the environment variables while being in an erroneous state, and also continues to restore (decode) AM RLC PDUs to be subsequently transmitted thereto by using the erroneous environment variables. As a result, proper communication can no longer be continued.